home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19961006-19970104 / 000366_news@columbia.edu _Fri Dec 27 12:42:41 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB

  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.8.3/8.8.3) with ESMTP id MAA23141 for <kermit.misc@watsun.cc.columbia.edu>; Fri, 27 Dec 1996 12:42:40 -0500 (EST)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.8.3/8.8.3) id MAA00835 for kermit.misc@watsun; Fri, 27 Dec 1996 12:42:39 -0500 (EST)
  4. Path: news.columbia.edu!panix!news-xfer.netaxs.com!news.voicenet.com!omni2!cmosley
  5. From: cmosley@voicenet.com (Christopher Mosley)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Not really a kermit question
  8. Date: 27 Dec 1996 17:33:34 GMT
  9. Organization: Voicenet - Internet Access - (215)674-9290
  10. Lines: 45
  11. Message-ID: <5a119e$c6f@news1.voicenet.com>
  12. NNTP-Posting-Host: omni2.voicenet.com
  13. X-Newsreader: TIN [version 1.2 PL2]
  14. Xref: news.columbia.edu comp.protocols.kermit.misc:6324
  15.  
  16. Hello,
  17.  I noticed that I had poor throughput during most of my sessions.
  18. I tested this using mskermit and ckermit by using up/downloads during
  19. serial dialin sessions. This is what I discovered:
  20.  
  21.  28.8 connection 115200 modem speed, windows 5, packet size 5000,
  22.  42.bis compression,rts/cts. 
  23.  
  24.  1. A session fell into one of two categories either a throughput of
  25.  3500 - 3900 cps or 6000 - 6500 cps for a text file (always the same file).
  26.  The througput for a precompessed file was always ~3200 cps - this
  27.  to assure that that varying line conditions did not account for the
  28.  disparity. ~3200 was also the rate for a non-compressed session for
  29.  any kind of file. During any one dial in session the cps did not change 
  30.  from the slower realm to the faster or faster to slower.
  31.  
  32.  2. Varing packet-lengths had no effect other than to slow or speed
  33.  up everythimg by the expected amount.
  34.  
  35.  3.These results were basicly the same at all times: the likelyhood   
  36.  of having a good or bad session was the same,  1 out of every 5 
  37.  sessions was 'a good one'. This was during times of heavy or light
  38.  load on the remote. It was possible to have a good session at times
  39.  when the load on the remote was the heaviest and to have a bad
  40.  session when the the lightest.
  41.  
  42.  4. The results were about the same for mnp compression.
  43.  
  44.  What I wonder.
  45.  
  46.  1.It seems that compression is occuring, but what is this 
  47.  partial compression! ;-( , 3800cps for a file a file that would
  48.  have a transfer rate of only slightly less (3200 cps)
  49.  when a compression free connection was made?
  50.      
  51.  2. Is it possible that some modems implement feeble
  52.  compression?
  53.                              
  54.  The reason I am posting here is the responses/suggestions I have gotten are.
  55.  
  56.   Don't use kermit. ?
  57.   Shouldn't use packet lengths of over 1024 on a hayes compatible modems. ?  
  58.  
  59.                                                   Thanks 
  60.                                                   cmosley